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ABSTRACT 

The Shuttle Imaging Radar - C (SIR-C) mission will 
operate from the payload bay of the space shuttle for 
8 days, gathering Synthetic Aperture Radar (SAR) 
data over specific sites on the Earth. The short 
duration of the mission and the requirement for real- 
time planning offer challenges in mission planning 
and in the design of the Planning and Analysis 
Subsystem (PAS). The PAS generates shuttle 
ephemerides and mission planning data and provides 
an interactive real-time tool for quick mission 
replanning. It offers a multi-user and multi- 
processing environment, and it is able to keep 
multiple versions of the mission timeline data while 
maintaining data integrity and security. Its flexible 
design allows one software to provide different menu 
options based on the user's operational function, and 
makes it easy to tailor the software for other Earth 
orbiting missions. 
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1. INTRODUCTION 

Shuttle Imaging Radar - C (SIR-C), together with the 
X-Band Synthetic Aperture Radar (X-SAR) of 
Germany, is a mission currently scheduled for three 
flights on the space shuttle, the first of which will be 
in October 1993. The second and third flights are 
scheduled in two different seasons of 1995 and 1996. 

SIR-C's instrument is a Synthetic Aperture Radar 
(SAR). It will operate from the shuttle's payload 
bay, gathering 50 hours of data over numerous sites, 
and it will return with the shuttle after each flight. 
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The data returned from this mission will provide the 
science community with simultaneous multi- 
frequency, multi-polarization, and multi-parameter 
radar imagery from space. A complete science plan is 
documented in the SIR-C Science Plan (Ref. 1). 

Each flight of SIR-C will last 8 days. Mission 
operations will be performed from a Payload 
Operations Control Center (POCC) at the Johnson 
Space Center (JSC). Due to the short duration of the 
mission, 24-hour continuous operations is planned. 
Timely replanning and quick responses to real-time 
anomalies are essential to the success of the mission. 

The Planning and Analysis Subsystem (PAS) is a 
part of the SIR-C Mission Operations System (MOS) 
currently in development at the Jet Propulsion 
Laboratory. This paper will describe the SIR-C 
mission planning scenario and the design of PAS 
which supports that scenario with a multi-user, 
multi-processing environment using interactive 
software which allows real-time replanning. 

2. MISSION PLANNING SCENARIO 

Pre-flight mission planning activities are currently 
under way to develop a baseline mission timeline. 
Datatakes are a major part of the baseline timeline, 
which also includes playbacks of recorded data and 
live downlinks. During the mission, these datatakes 
will be replanned as necessary based on the navigation 
data received from JSC. 

Major perturbations to the orbit, such as shuttle 
attitude maneuvers required for the mission and trim 
bums which may be required to maintain the mission 
trajectory, contribute to relatively large uncertainties 
in orbit determination by JSC Navigation. The errors 
in atmospheric modeling at SIR-C's low average 
reference altitude of 215 km further contribute to the 
uncertainties in orbit prediction. These errors quickly 
propagate to greater uncertainties as a function of 
time. Preliminary analysis has indicated that after 6 
hours of orbit propagation, the science requirement of 
imaging a site within ±4 km 90% of the time will 
not be satisfied. 
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In order to meet the site imaging accuracy 
requirement, SIR-C mission replanning will be 
performed in two stages: long-term planning in 12-hr 
cycles to update the planned datatakes in the baseline 
timeline, and real-time planning to update the radar 
parameters for each datatake scheduled during the 
long-term planning cycle. 

Every 12 hours, an ephemeris will be generated with 
the most current navigation data from JSC. This 
ephemeris data, which will span from the beginning 
of the planning cycle to the end of the mission, will 
be compared against the current baseline ephemeris. 
The extent of the differences found from this 
ephemeris comparison, the status of data collection 
from the start of the mission, and any new mission 
constraints will be incorporated into the long-term 
replanning of the datatakes scheduled for the next 12 
hours. Some planned datatakes may be deleted, some 
new ones may be added, and some may be updated 
with parameter changes. 

The portion of the mission timeline updated during 
the long-term planning cycle is then verified and 
updated again during real-time planning. With the 
navigation data received from JSC on the average of 
once per orbit, approximately every 90 minutes, 
ephemeris data for the next few hours are generated 
and used to update the radar setup parameters for each 
upcoming datatake. Deletions and additions of 
datatakes are not a part of nominal real-time planning 
activities, although the real-time planner must be able 
to perform such activities if it becomes necessary in 
the event of an anomaly. 

The updates to the timeline planned during the long- 
term planning cycle are approved by the appropriate 
persons of the SIR-C operations team as well as by 
JSC. Once signed off, they are incorporated into the 
approved timeline, which is used by the entire 
operations team to carry out their responsibilities. 

3. FUNCTIONAL REQUIREMENTS AND 
DESIGN CHALLENGES 

The development of the Planning and Analysis 
Subsystem (PAS) was presented with some 
interesting design challenges. While the PAS must 
provide the tools necessary to perform the functions 
described in the planning scenario above, it must also 
satisfy the needs of the entire operations team, who 
must be able to view the approved mission timeline 
at all times. 

To support the mission planning activities, the PAS 
must perform high precision calculations for 
generation of mission planning data, must present the 
data to the users such that right decisions and tradeoffs 


can be made efficiently, and must provide a quick 
response time for real-time replanning. 

Some of the major functions of the PAS include 
processing of the state vectors from JSC, generation 
of ephemeris data and mission planning data, 
providing tools to develop a timeline of events, 
graphical displays of ground tracks, sites, and radar 
swaths against a world map, calculation of radar 
parameters, and constraint checking. 

It must be able to maintain the approved timeline 
while the changes to the datatakes are planned, 
approved, and finally incorporated into the approved 
version. And since there are two planners, a long- 
term planner and a real-time planner, who are both 
making updates to the approved timeline, the PAS 
must be able to keep their activities separate from 
each other, and furthermore, keep their activities 
separate from the approved timeline data until the 
changes are ready to be incorporated. 

There are several users of the PAS who must have the 
write access to specific mission data in order to 
support mission replanning and operations activities. 
All other users must be prevented from writing to the 
mission data. It is crucial that the write access to the 
data is strictly enforced. 

The mission planning data, as well as the approved 
mission timeline data, must be viewable by each 
position on the operations team, and the set of data 
viewed by one position can be different from that 
viewed by another depending on the functions of the 
positions. It is also possible, during the mission, 
that an anomaly may result in a change in one’s 
operational position, requiring that person to have 
access to the tools necessary to perform the functions 
of the new position. The provision of the appropriate 
software tools must be accomplished very quickly to 
minimize interruptions to the mission planning 
process. 

The goal was to develop one PAS system that 
provides the necessary control of the software and the 
data to guarantee its security and the integrity, has the 
flexibility required to support a very dynamic mission 
planning and operations scenario, and has the 
adaptability for responding to anomalies. 

4. SYSTEM ARCHITECTURE AND DESIGN 

The PAS system consists of a computer network, a 
central database, and software tools to aid in mission 
planning. Described below are some of the major 
features of the PAS system which satisfy the 
functional requirements and provide answers to the 
design challenges. 
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4. 1 Computer System and Data Storage 

The PAS operates in a local area network which 
includes one host computer and several workstations 
which communicate with the host via ethemet. 

One operational copy of the PAS software and the 
data reside on the host, and they are accessible by all 
workstations in the network. This configuration 
allows all users to have access to the most current 
data as they are continually updated. It also 
guarantees that all users are using the same version of 
the software 

Some of the data in the host computer are stored as 
ASCII files, but most of the data are housed in a 
relational database. The database environment and the 
PAS software together control the multiple user data 
access in order to ensure data integrity and security. 

The PAS fully utilizes the multiple windowing 
capabilities of the workstations as well as colors and 
controls using the mouse. These features increase 
user productivity, which is an important consideration 
for quick real-time replanning. 

4 .2 Central Database and Data Access Control 

The PAS has a central database which is located on 
the host computer, and it holds most of the mission 
planning data and the timeline data. The data are 
organized into many tables with specific links defined 
in order to provide faster response time for more time 
consuming activities. 

All users of the PAS are assigned to one of several 
groups, and each group has different access privileges 
to the database. The read access to these tables is 
granted to all groups, but the write access to each 
table in the database is limited to those groups 


responsible for maintaining the data in that table. In 
most cases, the write access to a table is limited to 
only one group. 

The database also serves as the main interface between 
the software modules. The input data to each module 
are read from the database, and the output data are 
written back to the database, either to be read by 
another module or to be displayed to the user. 

4.3 One PAS for Multiple Users 

The software modules are integrated into one software 
package with a top level menu that reads the user id, 
retrieves the group to which the user is assigned, and 
presents only those menu options that are granted for 
that group. This design of the PAS allows one 
software to be used by several users performing 
different functions. 

If a user is reassigned to perform the functions of a 
different group, one entry in one table is modified to 
assign the user to the new group. In less than a 
minute, this user will have a new set of menu 
options allowing him/her to have the tools necessary 
to perform the new functions. 

Figure 1 shows a small portion of the PAS top level 
menu and illustrates the differences between the menu 
options displayed for two different groups. 

The menus are designed to support multi processing, 
with the number of processes and the types of 
processes selected by the user. Two users in the same 
group, although they have access to the same menu 
options, can choose to initiate only those processes 
applicable to their operational function. With this 
flexible design, the PAS display can have several 
forms, each tailored to the specific needs of each user. 
An example is shown in Figure 2. 
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Figure 2. An Example of 
User Defined Multi-processing 


4.4 Timeline Development Tools 

The timeline development process begins with an 
arrival of the navigation data from JSC and ends with 
an approved timeline from which the commands are 
generated. 

After the navigation data are electronically received 
from JSC, a coordinate transformation is performed to 
make it compatible with the coordinate system used 
by the PAS, and then it is stored in the database. 
User-selected state vectors from the database are read 
into an orbit propagator which generates the 
ephemeris data as well as the ground track data and 
stores them in an ASCII file. Certain parameters 
from the ephemeris file are ported into the database so 
that they can be manipulated easily. 

Sites selected by the SIR-C Principal Investigators 
are stored in the database also. These data can be 
updated interactively using the site editing module. 

The site data and the ephemeris data are used by 
another module which determines the data take 
opportunities by calculating the geometry necessary 
to image the sites. These datatake opportunities, 
which are stored in the database, can be viewed, 
sorted, searched, and finally selected as datatakes. 

Once an opportunity is selected as a planned datatake, 
the links between the different types of data are 
utilized to present complete information associated 


with a datatake. For example, the link between the 
opportunity data and the site data is used to retrieve 
the requested radar setup parameters for that site. The 
module which calculates the radar setup parameters 
uses the requested values as an input to determine the 
optimal radar setting for that datatake. 

Since all data will be recorded onto tapes on board the 
shuttle, sophisticated tape management modules are 
available to automatically assign datatakes to tapes 
and plan tape loading and unloading events. The 
automatic tape assignments can be modified using the 
manual mode. Playbacks of data recorded on tapes are 
easily planned by displaying the content of the tapes 
and selecting the datatakes to be played back. Useful 
tape information, such as the percentage of each tape 
used, is readily available to the user. 

Figure 3 shows the data storage, the external 
interfaces, the processes, and the interfaces between 
the processes described in this section and in sections 

4.5 to 4.8. Note that this diagram illustrates only the 
functions discussed in this paper; it does not represent 
the entire PAS system. 

4.5 Constraint Checking 

Constraint checking, which is a very important part 
of mission planning, is also supported by the PAS. 
It is used to resolve conflicting activities, to check 
against power and energy constraints, and to verify 
tape assignments. The availability of Tracking and 
Data Relay Satellites (TDRSs) is also checked when 
data playbacks or live downlinks are planned. 

Any violations to the mission rules are flagged by the 
software, and the generation of commands will not be 
initiated until the timeline either passes the constraint 
checks or the flags are acknowledged and overridden 
by the user. 

4.6 Graphics Displays 

The PAS has color graphics displays which provide 
the user with visual representations of the mission. 

The mission planning data, such as ground tracks, 
sites, and potential radar swaths can be displayed 
graphically against a map of the world. Several 
options are available to tailor the display to the needs 
of the user. These options include zooming into a 
small area on the map, selection of overlays, labeling 
of orbit numbers and times, and output to a printer 
and a color plotter. One of the options most useful 
for the SIR-C mission is the capability to plot 
datatakes directly from the timeline, which will be 
used to plot daily coverage maps before, during, and 
after the mission. 
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Figure 3. PAS Mission Planning Functional Diagram 


All mission events stored in the database, both 
executed and planned, can be displayed on a graphics 
timeline. Colors are utilized to distinguish events 
and to alarm constraint violations. To assist users in 
planning certain activities, also shown on the same 
display is information such as TDRS availability and 
whether the shuttle is in daylight or night. 

Color graphics is also used to display the power used 
for each datatake and the energy consumption as a 
function of time. This display provides an overview 
of the power and energy status, therefore allowing the 
user to make appropriate decisions if the power and 
energy constraints are violated. 

4.7 Working Plan vs. Approved Plan 

While the approved plan in the database is used by the 
operations team, the planners can work on updates to 
the approved plan in separate working plans. Since 
there are two mission planners, a long-term planner 
and a real-time planner, there will be at least two 
working plans. 

When a portion of the approved timeline is identified 
for updates, that portion is checked out by a planner, 
and the software marks those events in the approved 
timeline so that the operations team can see which 
portion is in the process of being updated by a 
planner. The software prevents the other planner 
from checking out the portion of the timeline already 
checked out by the first planner. Operational 
procedures dictate that the two planners do not work 


on the same portion of the approved timeline; the 
software safeguards against accidental overlaps. 

4.8 Updates with Actuals 

The Telemetry Processing Subsystem of the SIR-C 
MOS receives and processes the telemetry data. 
Some parameters in the telemetry data are routed to 
the PAS, and they are used to update the events in the 
approved timeline with the actuals. For example, the 
datatakes are updated with the actual on and off times 
as well as the actual tape start and stop identification 
numbers. These updates are performed immediately 
following a completion of an event. 

Actual energy consumption data are received from 
JSC every 12 hours, and this information will also be 
entered into the database and compared against the 
predicted values. Adjustments in the software 
parameters can be made if there is a significant 
difference between the predicted and the actual energy 
consumption so that the remainder of the mission can 
be planned with more accurate energy constraints. 
The adjustments are made by simply updating the 
software input parameters stored in the database; no 
changes to die code will be necessary. 

Figure 4 is a graphical representation of different 
stages associated with the timeline. Events are 
initially planned in the pre-flight baseline timeline; 
they are then updated during a long-term planning 
cycle; further updates are made during real-time 
replanning; and after the execution of the events, they 
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are updated with actuals. At the end of the mission, 
the timeline becomes the as-flown timeline. 


TIMELINE AT MISSION START 
iHH pre-flight baseline || 


TIMELINE DURING THE MISSION 
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of maps and overlays utilize the VAX Graphical 
Kernel System (GKS). Fortran is the language used 
for the 3gl programs. 

Two sets of software have been inherited from the 
Mission Design Section of JPL for the development 
of PAS: the Vector Library of the Multimission 
Analysis Software Library (MASL), and the Planetary 
Observer High Precision Orbit Propagator (POHOP) 
of the Planetary Observer Planning Software (POPS) 
(Ref. 2) 

The PAS software is developed in small modules. 
Each module is integrated into one of several 
applications, and one main application, which 
provides the main menu, calls other applications as 
they are selected by the user. This development 
strategy offers flexibility in software development, 
simplifies the debugging processes, provides easier 
software maintenance and configuration control, and 
accommodates future upgrades and changes. 


TIMELINE AT MISSION END 



Figure 4 Stages of Mission Timeline 


4.9 Parameter Updates in Response to Anomalies 

Similar to the way an adjustment is made to the 
energy consumption software module, other software 
parameters can be changed to respond to certain 
anomalies during the mission. Many parameters 
relating to mission planning and operations are stored 
in tables in the database, making it possible for quick 
updates with very little impact to the mission 
planning process. 

For example, there are 16 different Pulse Repetition 
Frequencies (PRFs) available for SIR-C datatakes. 
Nominally, all 16 PRFs are considered when 
calculating radar setup parameters for each datatake. If 
one PRF becomes unusable as a result of an 
anomaly, that PRF will be marked as 'not available' 
in the database, and it will not be presented to the 
user in the list of possible PRFs. 


6. APPLICATION TO OTHER MISSIONS 

Although PAS is being developed specifically for the 
SIR-C mission, many features of the system can be 
used for other Earth orbiting missions. Some 
capabilities of the current working version of the 
PAS have been used to perform preliminary mission 
design for EosSAR and for other Earth orbiting 
mission proposals. 

Because PAS is flexible and modular in its design, 
changes necessary to support other missions can be 
performed fairly easily. The preliminary versions of 
the SIR-C PAS have been delivered to the X-SAR 
project, who plans to make modifications and 
additions to support X-SAR mission planning. 
SIR-C and X-SAR mission planning will be 
performed jointly from a Payload Operations Control 
Center at JSC. 
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